Release the BATs(block level access control in IPFS)
= ファイルへのアクセスを許可された人だけがそのファイル構成する暗号化されたブロックを取り出すことが出来るようになっている
許可した人じゃないと取り出せないようになってるYudai.icon
IPFS上のアプリがデータブロックを必要とする場合、IPFSにコンテンツ識別子(CID)に対応するデータを要求します(基本的にはデータのハッシュ)。IPFSは、このCIDを持つノードをグローバルなIPFSネットワークで検索します。同時に、すでに接触しているノードに、「このCIDを持っていますか?「このCIDを持っていますか」と尋ねます。このCIDを持っているノードは、そのデータで応答することができます。この仕組みの優れた点は、コンテンツを持つどのノードもそれを提供できることで、つまり需要に応じてオートスケールできることです。
https://scrapbox.io/files/648035dc2fb355001b28c93a.png
このプロトコルを拡張して、すべてのCIDと対になるオプションの認証文字列を持つようにしました。Peergosでは、この認証文字列はS3 V4署名で、時間制限があり、CIDを含み、リクエストノードの公開鍵と結びついています(リプレイ攻撃を防ぐため) https://scrapbox.io/files/648036707cee01001b723404.png
ブロック自体を暗号化しているというより、ブロックを取得するのに許可されていないノードは保存できないてきは?
これある意味既存のCIDを拡張している
これ新しい仕組みにした場合既存のCIDとどうにか組み合わせることって出来るんかな
chatGPT.iconの解説
このアクセス制御メカニズムは、Bitswapプロトコル(IPFSのブロック交換プロトコル)を拡張し、CID(Content Identifier、コンテンツのハッシュ)ごとにオプションの認証文字列(auth string)を設けることで実現されています。このauth stringはS3 V4署名として実装されており、時間制限があり、CIDを含み、リクエストを行うノードの公開鍵に紐づいています。これにより、認証トークンの再利用(リプレイ攻撃)を防ぐことができます。 BATは、ブロック自体から導出される主要な認証要素です。これにより、認証された後にブロックを取得した任意のインスタンスは、同じアクセス制御を維持しながらそのブロックを提供し続けることができます。これにより、プライバシーを保護しながら自動スケーリングの性質を維持できます。
Peergosでは、ブロックにはcbor形式とraw形式の2種類があります。cbor形式のブロックでは、BATを格納する場所を選ぶことが容易です。一方、raw形式のブロックでは、BATを含まないブロック(既存のブロックまたは明示的に公開されたブロック)もサポートする必要があります。そのため、raw形式のブロックでは、8バイトの固定プレフィックスの後にBATのcborリストを配置し、その後に実際の暗号化テキストを配置するという設計が採用されています。 通常、各ブロックには2つのBATがあります。1つはそのブロック固有のもの(インラインBAT)、もう1つはユーザー全体をカバーするもの(ミラーBAT)です。ミラーBATは、ユーザーが自分のデータを別のインスタンスにミラーリングしたい場合や、別のインスタンスに移行したい場合に使用します。ファイルやディレクトリの各5 MiBチャンクは独自のBATを持ち、サーバーはファイルの異なるブロックをリンクしてファイルのパディングサイズを推測することができません。ファイル内の後続のチャンクBATは、CHAMPラベルと同様に、現在のチャンクBATとストリーム秘密(最初のチャンクに暗号化されて格納されている)をハッシュ化することで導出されます。これにより、任意の大きさのファイル内でIO操作なしにシーク(移動)する能力を維持します(ローカルハッシュ化と最終的なリクエストされたチャンクのルックアップだけで済む)。ファイルやディレクトリへの誰かのアクセスが取り消されると、BATも変更され、以前のアクセス権限を持っていても新しい暗号化テキストを取得することはできません。 このように、IPFSのブロックレベルアクセス制御は、BATという新しいコンセプトを導入することで、IPFS上でプライベートなアプリケーションのセキュリティとプライバシーを大幅に強化しています。各ブロックに固有のアクセス制御を導入することで、IPFS上でデータを公開することのリスクを大幅に減らし、安全にデータを共有することが可能になりました。